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INTRODUCTION 

Space Transportation systems of the future 
will be required to operate in an autonomous 
fashion for several years at a time in very 
remote environments (low earth orbit, on the 
moon, and other planets). This fact coupled with 
the fact that maintenance man hours will be 
severely limited and ground based personnel 
implementation of test and diagnostics will be 
too costly for even the most optimistic budget 
scenario leads us to conclude that on orbit test, 
checkout and diagnostics must be highly 
automated and implemented with the same 
degree of emphasis and importance as functional 
capabilities. 

At the recent space transportation avionics 
technology symposium, it was pointed out that 
over 50% of the space shuttle budget is required 
for operations. All attendees agreed that a 
primary contributor to this fact was the lack of 
automation in the test and checkout process and 
the FDIR system. Future systems must 
incorporate automated systems, which are well 
within our present state of the art capability. 
The Department of Defense has made major 
strides to eliminate operational costs via the 
implementation of self-diagnosing systems on all 
major new aircraft and weapon systems. 

The key to implementing self-diagnosing 
design is a systems engineering task focused on 
design for testability concurrent with design for 
functionality. 

The design for testability process described 
herein is the product of several years of DOD 
study and experience. Its application to the 
space station has begun on Work Package II 
under NASA and McDonnell direction. Other 
work package teams are being briefed by Harris 
Corporation (with hope) of convincing them to 
embrace the process. 

WHAT IS TESTABILITY 

For the purpose of this discussion the term 
testability is used to describe the systems 


engineering process by which designers can 
assure themselves and their reviewers that their 
designs are "TESTABLE," that is they will support 
the downstream process of determining their 
functionality. Due to the complexity and density 
of present-day state-of-the-art designs, such as 
pipeline processors and high-speed integrated 
circuit technology, testability feature design is a 
critical requirement of the functional design 
process. 

THE OBJECTIVE OF TESTABILITY 

In most cases an individual is interested in 
only one of many uses or reasons for making an 
item "TESTABLE” or they are involved in only 
one step in the testability process. However, the 
needs for testability in a product cover such 
areas as FDIR, maintainability, safety, design 
verification, and acceptance testing of the "as- 
built” product. Each of these uses has special 
requirements which can be met through 
providing embedded test points or 
instrumentation, providing means to open closed 
loop systems, and using other approaches which 
increase ones ability to measure the 
functionality of the product, and to some level of 
detail, it's component parts. This is usually 
accomplished with some associated processing 
software either embedded or in test equipment. 
The key objectives of the manned space program 
testability design process are listed in Figure 1. 


• Optimize System FDIR 

• Optimize System Test and Verification 
Interfaces 

• Minimize Weight and Power of BITE 

Figure 1. 


THE PROCESS 

Figure 2 depicts the flow of system/ORU 
testability and test procedure development 
activities which should be integrated into the 
system/ORU design process. 
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Maintenance man-hour constraints, astronaut 
skill level, and other logistics analysis constraints 
are used to determine on orbit testing 
requirements. The level of ground participation 
in operational testing as well as pre-launch test 
and verification needs are summed up as ground 
test requirements. With this data the systems 
engineering process of testability design can 
begin. 

The first step in the process is to allocate 
testability requirements to BIT vs. on-orbit 
management systems vs. ground-based work 
centers. These requirements which involve built 
in system/ORU interfaces and/or processing for a 
summary list of testability requirements which 
must be addressed by system/ORU designers. 
Items such as fault isolation to one or more 
ORU's with attendant confidence factor would be 
a particular element of such a requirements 
document as would mean time to isolate, etc. 

Given these requirements the systems 
engineering team can concurrently design to the 
functionality and testability requirements of 
their system/ORU. 

The testability analysis process is one in 
which the design as defined by a CAE net list or 
equivalent representation is evaluated manually 
or computer aided by a system’ testability 
analysis software tool to detect design features 
which threaten the downstream testing process. 
Such features as closed loop processes, which 
have no mechanism built in to break the loop, 
are typical. So the CAE design is iteratively 
challenged prior to completing detail design to 
insure testability. A second step in the process 
involves the generation of a suitable monitoring 


and diagnostic strategy for the item being 
designed. This process as was the case in 
testability analysis can be accomplished in a 
manual fashion or computer aided using the 
system testability analysis model. The product 

of this task is the detail definition of built in test 
functions such as test points, signal conditioning, 
and/or data processing which are required to 
implement the monitoring/diagnostic process. 
As the system is being designed and developed a 
parallel activity is conducted by the diagnostics 
engineer, which will yield test software for both 
the embedded (on orbit) and off-line (most 
likely ground based) fault management system. 
As in the case of testability analysis, this 
software generation process can be accomplished 
using computer based software products which 
will generate machine code to match detail 
testing procedures for both embedded 
diagnostics and off-line ATE diagnostics. 

At the present time Harris Corporation and 
McDonnell Douglas are applying computer aided 
testability analyses to the systems of Work 
Package II. Figure 2 depicts the process which is 
being implemented. Using JSC 31000 guidance, 
testability requirements are being documented 
in a station level FDIR specification. These 
requirements are supplemented with RM+S data 
to form a complete set of station level data. The 
first task in this process is to develop a 
dependency model description of the station 
level connectivity of the Work Package II 
systems. The testability analysis process is then 
used to describe a station level diagnostic 
strategy. The main task of this diagnostic 
strategy is to do the processing and control 
functions which are necessary to resolve 
conflicts between systems. It is that software 



Figure 2. Test and Checkout Development Process 
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which resolves multiple fault alarms and covers 
those faults which cannot be handled by the 
individual systems FDIR software. 

Having completed this first step, a 
specification will be developed which will 
describe the functions which must be 
implemented by the OMS system and it will 
describe for the individual systems design teams 
(COM + TRACK, GNC, DMS, etc.) the data which 
they must deliver to OMS to support the station 
level diagnostics process. 

The remainder of Figure 3 shows the activity 
which will take place within the system level 
design teams organizations. 


general all of the tools approach the problem 
from the perspective of modeling the 
system/ORU under test using dependency model 
representation. Once the computer aided design 
work station has developed this representation, 
several processor functions are called in to 
assess testability and interact with the design 
engineer in a user friendly fashion to help him 
correct problems noted. Once the system/ORU 
testability features are included in the design, 
work begins on the process of selecting optimum 
search strategies which form the diagnostic 
(fault tree) approach. Having arrived at this 
point in the process, an optimum set of test 
points and test procedures are developed for 
implementation. 


The overall impact of this analytically derived 
top down test strategy development process is 
an optimization of test point allocation and 
minimization of data bus traffic, since only data 
necessary to satisfy the next level of test will be 
passed from individual built-in test processors. 
Experience on several large DOD Programs has 
shown that unless this process is implemented, 
each system and ORU designer will make a 
judgment as to what data could be used by the 
next level diagnostic processor and this leads to 
computational and data handling explosion. 


One such testability analysis model has been 
selected for the Space Station Freedom Work 
Package II activity. The selected tool is a 
product of a DOD development contract and as 
such is available to prime and subcontractor 
teams. The System Testability Analyzer Tool 
(STAT) will also be added to the space station 
Software Support System Environment (SSSE) 
tool set. Although this tool is being used for the 
station level work described above by 
McDonnell/Harris, other subcontractors may be 
more comfortable with their in-house tool. 


TESTABILITY TOOLS 

Over the past 10 years there have been 
various pockets of energy within major 
corporations and small systems engineering 
houses to develop testability analysis tools. In 


The space station testability analysis tool 
(STAT) is identical to the DOD Weapon System 
Testability Analyzer (WSTA) tool; this tool is 
described in detail in Reference I to this paper. 
Harris Corporation is the developer of this 
product and may be called for more detailed 
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information. The Harris contact is Dr. Bruce 
Rosenberg and he may be reached at (516) 677* 
2769. A compatible set of implementation tools 
are also being developed by the DOD and Harris 
Corporation which will soon be available to all 
contractors. The key tool among these is a 
generic expert diagnostics software package 
which is designed to be an embedded processor 
to execute the STAT developed test strategy 
within a system/ORU or /OMS processor. This 
tool has data bases which support improvement 
of testing efficiency over time and a rule based 
reasoner to accommodate multiple alarms and 
false alarm discrimination. It is expected that 
this DOD product will be widely used in both on 
orbit and ground based testing systems. 

IMPLEMENTATION OF TESTABILITY ON SPACE 
STATION FREEDOM (SSF) 

As described above* testability 
implementation on SSF is a distributed task. The 
prime contractor MDAC in the case of Work 
Package II will implement station level 
testability analysis and test strategy 
development which will be executed by the OMS. 
Each of the sub tier contractors (RCA, IBM, 
Honeywell, etc.) will implement system/ORU 
testability using software and processors within 
their systems. Since the SSF STAT will be 
available to ail work package contractors via the 
SSE tool box, it is expected that they will use it. 
This tool will be configuration managed by the 
DOD and Harris Corporation. 

TECHNOLOGY ISSUES IN TESTABILITY 

Figure 4 lists some of the technology issues 
being addressed by the SSF contractors and 
NASA. Although the STAT tool is available 

• TIMELY ACCEPTANCE BY SYSTEM DEVELOPERS 

• LACK OF NASA APPLICATION/PROOF OF CONCEPT 

• HOW MUCH TESTABILITY IS ENOUGH 

• QUANTITATIVE RELATIONSHIP OF TESTABILITY 
AND AVAILABILITY 

• NON UNIFORMITY OF CAE TO TESTABILITY TOOLS 
INTERFACES 

• TOOL USER FRIENDLINESS 

Figure 4. Testability Technology Issues 


today, the system developers are not yet totally 
aware of it. SSF will be the first real application 
of testability analysis and development within 
the space program. It is generally agreed that 
the process is required to insure maximum 
operational availability of SSF functions, but this 
must be communicated across all work packages. 
To accommodate automatic transfer of CAD data 
(net lists, etc.) to the STAT tool data base, 
preprocessors will be required for each CAD 
system. Two presently exist for Daisy and HP 
CAD systems. 

CONCLUSION 

A systematic approach to Space systems test 
and checkout as well as FDFIR will minimize 
operational costs and maximize operational 
efficiency. An effective design for the testability 
program must be implemented by all contractors 
to insure meeting this objective. The process is 
well understood and technology is here to 
support it. 
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